In 3GPP (Third Generation Partnership Project), a VoIP (Voice over IP) service is underway using an IMS (IP Multimedia Subsystem).
FIG. 1 shows an example of network configurations of a VoIP service using a 3GPP IMS. The network shown in FIG. 1 is constructed of IMS network 126, an operator's IP core network 124, a base station (eNB: e Node B) and wireless access networks 120 and 122 configured under the control of the eNB. In FIG. 1, terminals (UE: User Equipment) 100 and 102 are wirelessly connected to eNBs 104 and 106 via wireless access networks 120 and 122 respectively, and are connected to IP core network 124 via eNBs 104 and 106 respectively.
The IMS network is a network intended to perform information management for call control, routing of a signaling message (SIP: Session Initiation Protocol) of call control, and mutual connections among 3GPP legacy networks or networks other than 3GPP.
In IMS network 126 shown in FIG. 1, P-CSCFs (Proxy Call Session Control Functions) 108 and 116 are CSCFs that have contact with UEs 100 and 102. When transmitting an IMS signaling message (SIP REGISTER message, SIP INVITE message or the like), the UE searches for a P-CSCF to which the UE can be connected and transmits the IMS signaling message to this P-CSCF.
S-CSCFs (serving CSCFs) 110 and 114 are CSCFs that manage UE contact information and manage sessions. S-CSCFs 110 and 114 download necessary information from HSS (Home Subscriber Server) 118 when managing the UE contact information.
I-CSCF (Interrogating CSCF) 112 holds CSCF information between management domains (each of which is a network unit managed by each operator). For example, when the P-CSCF or S-CSCF does not have the next node information with which an IMS signaling message should be transferred, the IMS signaling message is transferred via I-CSCF 112. Furthermore, I-CSCF 112 may also confirm information of a CSCF, to which the message is transferred, by inquiring of HSS 118 the information. For example, a case will be described where an SIP INVITE message is sent.
In this case, the SIP INVITE message is first sent from a calling-side UE to a P-CSCF in a domain where the UE is located (calling side domain) via the IP core network and transferred from the P-CSCF to the calling side S-CSCF. After being subjected to appropriate processing at the calling side S-CSCF, the SIP INVITE message is transferred to an S-CFCS in a called side domain. In this case, the SIP INVITE message may go by way of I-CSCF 112. The called side S-CSCF transfers the received SIP INVITE message to a called-side UE via a P-CSCF.
The operator's IP core network 124 shown in FIG. 1 performs routing of communication data, QoS (Quality of Service) control, and management of position information of a terminal or the like.
FIG. 2 is a flow illustrating an example of a procedure until a VoIP call is made using a 3GPP IMS. FIG. 2 illustrates a flow example when UE 100 makes a phone call to UE 102. As shown in FIG. 2, an SIP INVITE message is transmitted from UE 100 to UE 102 via the IMS network (step (hereinafter, referred to as “ST”) 11), and an SIP 183 Session Progress message is transmitted from UE 102 to UE 100 via the IMS network (ST12). Thus, the SIP INVITE message and the SIP 183 Session Progress message are exchanged between the UEs, and communication-related negotiation is thereby performed.
An SDP (Session Description Protocol) offer added to the SIP INVITE message describes a mechanism used in VoIP communication. Examples of the mechanism described include a codec scheme or codec mode, and protocol-related candidates. The codec scheme or codec mode includes an element adopted for this codec such as a bit rate, algorithmic delay, or the number of channels. Furthermore, the protocol includes the type of an RTP (Real-time Transport Protocol) payload format or the like. Upon receiving the SIP INVITE message in ST11, UE 102 selects one mechanism from among a plurality of candidates described in the SDP offer and describes the mechanism in an SDP answer. In ST12, UE 102 adds the SDP answer to SIP 183 Session Progress message and sends it to UE 100.
The IMS network analyzes the mechanism selected by UE 102 and issues an instruction for allocating a resource corresponding to the analysis result to this call session to the IP core network. According to the instruction from the IMS network, resource allocation processing is performed in the IP core network and the wireless access network (ST13). When the resource allocation processing is completed, UE 102 calls the user (ST14), and when the user responds to the call, a 200 OK message is transmitted to UE 100 (ST15), and a call is started between UE 100 and UE 102 (ST16).
FIG. 3 shows an example of the SDP offer and SDP answer. In FIG. 3, with the SDP offer, UE 100 offers four modes: AMR-WB (Adaptive Multi Rate-Wide Band) bandwidth-efficiency mode, AMR-WB octet-align mode, AMR bandwidth-efficiency mode and AMR octet-align mode. Furthermore, the AMR bandwidth-efficiency mode is selected in UE 102.
The bandwidth-efficiency mode and octet-align mode follow an RTP payload format used for AMR (or AMR-NB: Narrow Band) and AMR-WB described in Non-Patent Literature (hereinafter, abbreviated as NPL) 1. Furthermore, NPL 2 defines the codec bit rate at this time to be AMR 4.75, 5.90, 7.40, or 12.2 kbps.
When necessary resources are not allocated in the resource allocation processing (ST13 shown in FIG. 2), this is regarded as a negotiation failure and the procedure is repeated over again starting from the transmission of the SIP INVITE message (ST11). For this reason, it is recommended to use a rather low, limited range of bit rates so that resource allocation is reliably performed. For example, NPL 3 supports AMR-NB: 4.75, 5.15, 5.90, 6.70, 7.40, 7.95, 10.2, and 12.2 kbps, and NPL 4 supports AMR-WB: 6.60, 8.85, 12.65, 14.25, 15.85, 18.25, 19.85, 23.05 and 23.85 kbps. NPL 2 recommends use of AMR-NB: 4.75, 5.90, 7.40 and 12.2 kbps, and AMR-WB: 6.60, 8.85 and 12.65 kbps.